040 Детектирование сбоев
- способы детектирования сбоев
- прямые
- косвенные
- RED метрики и 4 золотых сигнала
- Детектирование проблем до возникновения сбоя
Способы детектирования сбоев:
Прямые
По репортам пользователей
По сообщениям пользователя судить о сбоях можно, но плохо, так как это замедляет реакцию (по сути мы уже сильно опоздали, если пользователь уже успел не только нарваться на проблему, но и сообщил). Тем не менее это последний и самый надежный метод.
В больших компаниях надо наладить специальный процесс, каким образом SRE инженеры узнают про массовые жалобы пользователей. Каким образом поддержка может обратиться к SRE.
Это самый "дешевый" способ детектирования сбоев.
Автотесты (Prober)
Наиболее технологичный способ — автотестирование. Непосредственно гоняем тесты в продакшен непрерывно.
Требует разработки самих тестов, как правило на языке программирования. Тесты могут делать API вызовы в продакшен сервисы. Но, если сервис содержит пользовательский интерфейс, то придется использовать технологию вроде Selenium и другие сложные способы. Требуется квалификация разработчика.
Selenium позволяет запустить браузер и управлять им из языка программирования. Можно загружать странички и эмулировать действия пользователей и проверять реакцию приложения и получаемый результат. Вплоть до снятия скриншота получившейся картинки и сравнения ее с эталоном.
Часто эти тесты могут потребовать доработку в системе. Например, некоторые вызовы может оказаться нельзя делать, так как это делает настоящий пользователь — это может быть невозможно или ограниченно законом. Например, создание настоящих банковских счетов просто для теста невозможно. Невозмоно верифицировать паспортные данные и подобное. Для этого систему дорабатывают так, чтобы пометить вызов как тестовый, но пропускать некоторую функциональность — помечать аккаунт. Теоретически это добавляет новых проблем невозможных без этого дополнительного функционала. Но на самом деле ловит много глупых сбоев довольно хорошо, а добавляет меньше сбоев из-за ошибок в реализации самого функционала для тестирования.
Для системы процессинга логов мы делали тестирование, подмешивая специальные записи. Записи генерировались строго в указанное время, в указанном количестве с нужными заранее известными данными. Они были специально помечены, чтобы пользователь мог отличить такие записи от тех, что он послал самостоятельно, но конвейер оработки этих записей был 100% идентичным обыкновенным логам. С помощью этих записей мы могли очень точно замерять время процессинга записей, потерю единичных записей и другие параметры работы системы. Без такого подмешивания сложно было отличить — мы теряем записи или наши пользователи их не пишут, мы долго процессим записи или пользователь пишет нам неправильную временную метку. Все эти вопросы были решены конролируемым нами подмешиванием специальных сообщений.
Самодиагностика
Сервисы могут быть разработаны так, чтобы диагностировать свою работу и свое состояние.
Почти всегда встречается диагностика успешности API вызова. Любой вызов может завершаться с точки зрения самого приложения либо успешно, либо с ошибками, а которой тот как правило информирует пользователя сделавшего вызов. В HTTP для успешных вызовов используют коды возврата 2ХХ, а для завершившихся с ошибкой 5ХХ.
При разработке софта могут уделять мало внимания разработке классификации ошибок и правильной разметке типов ошибок. Так некоторые проблемные запросы могут получать ответы 2XX. Еще чаще путают ошибочные запросы пользователя (которые должны получать ответы с кодом 4xx) и ошибки внутри сервиса, которые получают коды 5хх.
Все это верно и для не HTTP вызовов. Надо уметь четко различать успешные вызовы. Вызовы, которые невозможно выполнить, потому что сам вызов сделан некорректно (ошибка вызывающего). И вызовы, которые мы не смогли сделать из-за внутрених проблем.
При отсутвии хаоса в сообщениях об ошибках по ним можно делать вызовы о функционировании системы.
Другой способ самодиагностики — встроенные в приложения средства, рассказывающие о состоянии сервиса. Это может быть специальный API, специальная страница (web), или набор метрик.
Как правило нас интересуют состояние всех внутренних подключений (к базе данных, и к сервисам, к которым мы делаем вызовы), состояния очередей, состояния всех важных переключателей (circuitbrakers).
Такая самодиагностика с легким доступом к ней (специальная страница или дашборд в Grafana) облегчает и детектирование сбоя и дальнейшее понимание технической причины. Если мы делаем такую самодиагностику в виде метрик, то мы еще можем сохранить историю для всех сигналов по самодиагностике.
Многие managed среды разработки содержат ряд готовых низкоуровневых сигналов по самодиагностике, например в Java легко через API получить информацию по работе GC, тредам, памяти и многое другое.
Базы данных так же часто умеют диагностировать свое состояние, состояние шардов, подключения и многое другое.
Современные cloud платформы содержат обязательное требование иметь хотя бы примитивную самодиагностику (liveness-endpoint) встроенную в код приложения и без этого приложение не сможет запуститься.
Косвенные
Наличиии проблем в продакшен можно отдетектировать по сильному отклонению метрик от обычной сезонности.
(todo): добавить определение сезонности
Для этого подходят любые сигналы. Например, если все пользователи массово начали ошибаться в вводе секретного СМС кода, то вероятно это не массовое помешательство, а что-то не так с сервисом. Насторожить может любое резкое изменение любого показателя.
Есть несолько способов детектировать сбои таким методом:
- задать верхнюю и нижнюю границу для показателя
- рассчитать вручную коридор для показателя в зависимости от времени/дня недели
- использовать машинное обучение (автоподбор интервала) для автоматического выяснения типичного поведения и поиска отклонений
- искать просто лишком резкие изменения (задать верхнюю границу для производной от метрики)
Такой способ определения сбоев является довольно "шумным", то есть порождает много ложных рабатываний или пропускает настоящие сбои.
Такой способ требует достаточной активности и количества пользователей, чтобы набиралось достаточно статистики. В зависимости от сезонности, например, ночью активность может падать настолько, что один странный пользователь может существенно повлиять на всю статистику и вам покажется, что ваш сервис сломался.
Этот способ детектирования сбоев как правило проще сделать, так как подходящие метрики чаще всего уже есть или их очень легко получить. К сожалению из-за ненадежности детектирования одного этого способа не достаточно для надежного детектирования сбоев.
RED метрики и 4 золотых сигнала
RED часто используемая абревиатура обозначающая часто используемые сигналы для детектирования сбоев:
- Requests (запросы) — обозначает количество запросов/транзакций
- Errors (ошибки) — количество ошибок произошедших при обработке этих запросов
- Duration (длительность) — имеется в виду длительность выполнения запроса (стреднее, перцентили)
Певый и последний сигналы очень ценны для косвенного детектирования сбоя по отклонениям от ожидаемых значений.
Второй показатель был разобран, когда рассматривали самодиагностику системы.
К этим сигналам часто добавляют четвертый сигнал — насыщенность и тогда говорят о 4 золотых сигналах.
Насыщенность — то, насколько мы близки к максимому пропускной способности системы (обычно выражается в процентах).
Детектирование проблем до возникновения сбоя
Самодиагностика может проверять опциональные детали, которые не приведут к заметным сбоям сразу, а только по мере накопления. Тогда можно не регистрировать сбой, а просто привлекать внимание инженеров, часто только в будние дни.
Примеры:
- Все ли переехало с хот на ворм вовремя
- Достаточно ли места на диске
- Не устареют ли скоро SSL сертификаты
- Достаточно ли свежие данные используются для поиска
С этими параметрами можно играться добавляя условия, например, что релиз возможен только в случае "идеального" состояния системы (пройдены все расширенные проверки)